Repository navigation
fix(deparser): keep qualified relation in LIKE and REFRESH MATERIALIZED VIEW - #361
Open
R3gardless wants to merge 1 commit into
Open
R3gardless wants to merge 1 commit into
R3gardless wants to merge 1 commit into
Conversation
…ED VIEW TableLikeClause.relation and RefreshMatViewStmt.relation are bare RangeVar objects, not Node-wrapped. Passing them to visit() dispatched on the first object key instead of the node type: an unqualified relation starts with "relname" and happened to hit the relname() helper, but a qualified one starts with "schemaname"/"catalogname" and rendered as an empty string, e.g. CREATE TABLE t (LIKE s.p) -> CREATE TABLE t (LIKE ). Call RangeVar() directly, like the other bare-RangeVar fields.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A schema- or catalog-qualified relation is dropped when deparsing
CREATE TABLE ... (LIKE ...)andREFRESH MATERIALIZED VIEW, which produces SQL that no longer parses. Bothpretty: trueandpretty: falseare affected (reproduced on 18.3.12). Unqualified names work.CREATE TABLE t (LIKE s.p INCLUDING ALL)CREATE TABLE t (LIKE INCLUDING ALL)CREATE TABLE t (LIKE s.p)CREATE TABLE t (LIKE )→syntax error at or near ")"REFRESH MATERIALIZED VIEW s.mvREFRESH MATERIALIZED VIEWRoot cause
TableLikeClause.relationandRefreshMatViewStmt.relationare typed as a bareRangeVar, not aNode-wrapped{ RangeVar: ... }. Both visitors passed the field tothis.visit(node.relation as any, ...), andvisit()dispatches on the object's first key:relname, so it hit therelname()helper, which happens to return the quoted name (this is whyLIKE pworked);schemaname(orcatalogname), so it hit theschemaname()helper, which finds noString/svalon the object and returns''.Fix
Call
this.RangeVar(node.relation, context)directly, the same way the other bare-RangeVarfields are handled (CreateStmt.relation,IndexStmt.relation, etc.). I checked every visitor that passes aRangeVar-typed field tovisit(), and these two were the only ones.RangeTableSample.relationis a wrappedNode, sovisit()is correct there.This is the same root cause as #348 (
PartitionCmd.name), which was fixed in #352. That fix did not coverTableLikeClauseandRefreshMatViewStmt.Tests
__fixtures__/kitchen-sink/misc/qualified-like-and-refresh.sql(unqualified, schema-qualified, catalog-qualified, quoted identifiers,INCLUDING/EXCLUDINGoptions,CONCURRENTLY ... WITH NO DATA). I regenerated it withnpm run kitchen-sink. It fails onmainwithINVALID_DEPARSED_SQLand passes with this fix.packages/deparser:npx jest: 313 suites, 749 tests, 424 snapshots, all passing.parse(deparse(ast))equalsast(ignoring locations) in both plain and pretty mode for the cases above, includingLIKE db.s.p INCLUDING DEFAULTS EXCLUDING INDEXES.